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HARDWARE OBJECT REQUEST BROKER ON A CHIP 
FOR GENERATING SEPARATE CONTROL AND DATA 
CHANNELS FOR IMPROVED THROUGHPUT EFFICIENCY 



10 



DESCRIPTION 



BACKGROUND OF THE INVENTION 



Field of the Invention 



The present invention generally relates to 
middleware techniques for tying together different 
software objects, and more particularly to hardware 
techniques for enhancing middleware in devices with 
15 embedded resources. 

Background Description 

Middleware is software that connects two or 
20 more otherwise separate applications across the 

Internet or local area networks, enabling the 
seamless integration of the separate applications. 
Typically, middleware provides services for 
managing security, access and information exchange 
25 so that a user of one application, having satisfied 

the security and access requirements of the 
application, is able to communicate with another 
application without separately satisfying the 
security and access requirements of the other 
30 application. Middleware hides the underlying 

complexity of managing the interaction between 
remote resources, thereby smoothing the development 
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path for new. networked applications combining these 
resources . 

For example, middleware enabled a disbursed 
community of physicists at different facilities 
5 across the globe to pool their computing resources 

to create a common grid for analysis of enormous 
amounts of data produced at the CERN high energy 
physics laboratory. Similarly, middleware services 
deployed across institutions of higher education 

10 enable students at one institution to have remote 

access to libraries and classroom content at other 
institutions without separate logins at each 
institution. Such services are also in evidence 
for drivers using electronic sensors to pass 

15 through toll gates in multiple jurisdictions. 

The underlying assumption of middleware 
implementations is for ''bridging the gap between 
the operating system.. .and the application, easing 
the development of distributed applications." 

20 While this architectural assumption has been useful 

in the development of the vast array of middleware 
implementations available today (e.g. Common Object 
Request Broker Architecture, or ''CORBA'') , each 
publicly available middleware implementation is 

25 based on the concept that an object or process 

residing in a microprocessor's operating system 
interfaces with other objects or processes residing 
on the same or other microprocessors. 

The extension of this middleware into the 

30 embedded world revolves around the implementation 

of a driver on the microprocessor, creating a 
platform-specific connection between the object or 
process residing in the microprocessor and the 
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embedded device. In the context of traditional 
distributed applications^ this architecture makes 
sense. However, for embedded devices this 
architectural assumption highlights inefficiencies 
5 that lead to higher power consumption for a given 

throughput . 

For example, radio equipment provides wireless 
communication and, in the current state of the art, 
commonly uses computers for encoding and decoding 

10 data and controlling embedded devices. The set of 

technologies for computer defined modulation and 
demodulation of wireless data is called Software 
Defined Radio (SDR) . Incompatibility and upgrade 
difficulty with radio equipment used for 

15 communication has prompted the military to define a 

middleware standard called Software Communications 
Architecture (SCA) in order to meet the objectives 
of the Joint Tactical Radio System (JTRS) . This 
standard defines interfaces that allow waveform 

20 applications (i.e. signal conventions for encoding 

data sent over a wireless communication channel) to 
run on multiple hardware sets. When connected to a 
JTRS network, radio equipment compliant with SCA is 
able to interoperate with other SCA compliant radio 

25 equipment independently developed and procured. 

In order to obtain interoperability, the data 
flowing from one embedded device to another is 
channeled through the on-board computer, resulting 
in a substantial bandwidth overhead- What is 

30 needed is a method for reducing this overhead. 
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SUMMARY OF THE INVENTION 

It is therefore an object of the present 
invention to provide a structure and method for 
5 reducing the bandwidth overhead from using 

middleware with embedded devices. 

A further object of the invention is to enable 
a more efficient connection between embedded 
devices supported by middleware. 

10 Another object of the invention is to provide 

an easy upgrade path for interoperating equipment 
supported by middleware by making it relatively 
easy to add new devices and swap operating devices. 
Yet another object of the invention is easier 

15 integration of reconf igurable computing platforms, 

and to isolate reconf igurable computing modules. 

It is also an object of the invention to allow 
direct connection of different platforms with 
little overhead in a general purpose processor. 

20 A further object of the invention is to 

provide for extension of middleware connections 
outside the general purpose processor, thereby 
allowing for efficient embodiment of customized 
connectivity approaches . 

25 Another object of the invention is to ease 

restrictions required to support power management 
on middleware supported systems having embedded 
devices . 

It is also an object of the invention to make 
30 it easier to integrate ASICs cores into system 

design . 
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A further object of the invention is to reduce 
the implementation cost of middleware supported 
devices having imbedded resources. 

Yet another object of the invention is to 
5 increase scalability of design by reducing the 

impact of bandwidth bottlenecks at the general 
purpose processor of middleware supported systems 
having embedded devices. 

All current implementations of middleware are 

10 designed explicitly to isolate different objects 

from each other and, hence, use a centralized form 
of control. By extending the functionality of the 
middleware into the interface of each of these 
objects and establishing a separate but controlled 

15 data channel, the present invention provides a 

solution aligned with the foregoing objects and 
suited particularly to middleware supported systems 
having imbedded devices. 

An aspect of the invention is an Object 

20 Request Broker (ORB) on a chip for controlling data 

transfer between embedded resources in a device 
using the ORB. The ORB on a chip separates the 
functionality of the ORB into a control interface 
and a data interface. This functionality enables a 

25 software object resident on a general purpose 

processor of the device to transfer data between 
embedded resources in the device, there being a 
control interface and a data interface for the 
object and each of the embedded resources. The ORB 

30 on a chip has circuitry for constructing the 

control interfaces within the general purpose 
processor of the device, and for constructing data 
interfaces for the embedded resources outside the 
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general purpose processor, such that data transfer 
between embedded resources, under control of the 
object and exercised through the control 
interfaces, occurs directly without going through 
5 the general purpose processor. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and 
10 advantages will be better understood from the 

following detailed description of a preferred 
embodiment of the invention with reference to the 
drawings, in which: 

Figure 1 is a diagram showing a basic computer 
15 system architecture. 

Figure 2 is a diagram showing how prior art 
middleware in a general purpose processor handles 
messages . 

Figure 3 is a diagram showing extraction of 
20 middleware functionality outside the general 

purpose processor . 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 

25 

In the case of embedded devices, a basic 
boundary constraint arises because of the limited 
ability of the system to support communications 
between different devices when a microprocessor is 
30 used as the core component for interconnections. 

Figure 1 shows the basic architecture of a typical 
personal computer having a microprocessor 110, a 
memory 120 connected to the microprocessor 110 
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through a hub 130, and two embedded devices (not 
shown) residing on PCI boards 140 and 145 (or 
equivalent structures) , respectively, and connected 
to microprocessor 110 through a hub 150. The two 
5 embedded devices can communicate directly through 

the use of the bus 160. Therefore, the maximum 
sustainable rate, C, that can be supported by the 
system is the bus delay, or 

10 However, when the microprocessor 110 is used 

to inter-connect these embedded devices, the data 
must be transported from an embedded device to the 
microprocessor 110 and then back to the target 
embedded device. Assuming that the data rate 

15 between the hub 150 and the microprocessor 110 is 

much higher than the data rate over the bus 160 
between the different embedded devices, then the 
maximum sustainable rate is now 

2 • r - + r 

bus proc 

2 0 where r^^^^ is the processing delay for managing the 

communications via the microprocessor 110. 

This additional effect can have a significant 
impact on the overall performance of a system. In 
combined microprocessor benchmarks and system 

25 simulations performed at the Mobile and Portable 

Radio Research Group at Virginia Polytechnic 
Institute and State University, the above effect 
was shown to reduce the supported bandwidth of a 
radio system by over 85%. This ratio can change 

30 depending on the level of granularity controlled by 

the microprocessor, but the use of microprocessor- 
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centric software can have a large and noticeable 
impact on the overall performance of a system 
having embedded devices. In particular, this 
effect can have a deep impact on Software Defined 
5 Radio (SDR) implementations using middleware. 

This effect may be further described with 
reference to Figure 2, where a general purpose 
processor (GPP) 210 contains middleware 220. The 
middleware 220 enables object 230 to use resources 

10 such as a Field Programmable Gate Array (FPGA) 241, 

a Digital Signal Processor (DSP) 242, and an 
Application Specific Integrated Circuit (ASIC) 243, 
without having to manage the interactions between 
these resources. The middleware 220 handles the 

15 communication with each of these resources through 

a respective wrapper 250 and device driver 255. 
However, data flowing between these resources 
passes through the general purpose processor 210 in 
response to the interoperability functionality of 

20 the middleware 220, as is shown by the data flow 

path 260 between the FPGA 241 and the DSP 242. In 
general, when two different resources are connected 
through middleware, regardless of what platform 
they happen to be implemented on, the GPP 210 must 

25 receive, process, and re-transmit all data passed 

between the two resources. 

The problem outlined above can be overcome by 
making the middleware software gluing these 
different components together a system-wide 

30 implementation, not a microprocessor 

implementation. To illustrate this approach of the 
invention, we will use CORBA (Common Object Request 
Broker Architecture) as an exemplar middleware 
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platform. CORBA is used by the JTRS (Joint 
Tactical Radio System) in its SCA (Software 
Communications Architecture) standard. However, 
while SCA specifications versions 2.2 and lower 
5 mandate the use of CORBA, future versions of the 

SCA will most likely allow use of middleware 
technologies other than CORBA. As those skilled in 
the art will appreciate, the invention can be 
practiced with middleware other than CORBA. 

10 To generate an interface between two objects 

under the prior art approach using CORBA, separate 
objects are created using C++, or some other OOP 
language, as well as an Interface Description 
Language (IDL) description of the interface methods 

15 within that object. This IDL file is used by the 

supplied code generator (which is specific to the 
Object Request Broker) to generate the skeleton and 
stub code for the appropriate object methods. This 
additional code is then compiled with the target 

20 object, generating new executable code that can be 

connected through CORBA' s ORB (Object Request 
Broker) . Using this prior art method, objects 
residing within the bounds of the operating system, 
and the current reach of the ORB, are connected. 

25 In contrast, the present invention provides 

diffuse middleware, that is, an Object Request 
Broker whose functionality is broken down into two 
separate pieces, the control and data interfaces. 
We will call this approach of the invention a 

30 ^'Diffuse ORB". The control object is written in 

some language like C++ and interacts with the 
device drivers. The interfaces for this object are 
created in the traditional way described above. 
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However, the data -interface for the embedded device 
is handled in a different way. For the purposes of 
this example, assume that the embedded device is a 
Field Programmable Gate Array (FPGA) and the system 
5 is a software defined radio (SDR) . An IDL 

description of the FPGA' s raw interface is written 
by the developer of the system. The IDL code is 
then used to generate, through another ORB-specific 
code generator, bit files that describe both the 

10 interface between the core functionality of the 

FPGA and the bus structure that the FPGA chip is 
connected to, as well as the controller necessary 
to perform this functionality. 

Another way of looking at this is that the 

15 IDL-generated code is used to create a bridge 

between the FPGA' s original interface and the new 
interface, as well as the desired target for the 
information or (in the case of an input interface) 
the required data to receive the information from 

20 the source. If no dynamic interfaces are used 

(which is the case in JTRS) , and because the SDR 
developer needs to know at the time of development 
the complete structure of the waveform, it is 
possible to determine which interfaces need to be 

25 created and to determine which platform will be 

used. 

From the description provided above, it should 
be clear that it is possible to build an ORB 
implementation that maintains all the desirable 
30 attributes of CORBA while at the same time giving 

the system developer the ability to establish 
separate data (hardware-centric) and control 
(microprocessor-centric) channels, thus increasing 
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the bandwidth that the system can support, or 
reducing the overall power consumption expected 
from the support of a waveform with a given signal 
bandwidth . 

5 The foregoing aspects of the invention may be 

further understood with reference to Figure 3, As 
with the prior art shown in Figure 2, there is a 
general purpose processor 310 on which resides an 
object 330 using embedded resources 341 and 342. 

10 However, as described above, in contrast to the 

prior art shown in Figure 2, middleware 320 is 
structured to break its functionality into separate 
control (371, 372) and data (381, 382) interfaces. 
For each embedded resource (341, 342) there is an 

15 entry point (391, 392) to the GPP (310), which is 

used by the control interface (371, 372) via the 
respective drivers (not shown) to complete a 
control connection between middleware 320 and the 
respective embedded resources (341, 342) . The data 

20 interfaces (381, 382) of the middleware 320 are 

provided in a different manner, being extracted 
outside of the GPP 310. A hardware switch matrix 
360 is provided for the device (e.g. an SDR), 
allowing different hardware components of the 

25 device (i.e. embedded resources 341 and 342) to 

communicate directly. The switch matrix 360 is a 
custom fabric that is used for the connection of 
multiple devices within a core or set of cores. By 
integrating the switch matrix 360 into middleware 

30 320, the switch matrix becomes a channel of 

communication integral to the middleware 320. 

Taking one embedded resource as an example, 
the control interface 371 for embedded resource 341 
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will interact with the device driver (not shown) 
for embedded resource 341 at a GPP entry point 391. 
The connection between the embedded resource 341 
and the GPP entry point 391 is made through the 
5 device driver (not shown) , and this connection is 

used for implementing the control functionality of 
middleware 320 through control interface 371, The 
data interface 381 of middleware 320 is moved 
outside GPP 310 by use within middleware 320 of 
10 switch matrix 360, enabling direct data connection 

between embedded resource 341 and any other 
embedded resources within the device served by GPP 
310. 

The approach of the invention offers the 
15 capability of leveraging the best aspects of 

middleware such as CORBA, namely, coupling CORBA' s 
ability to provide an abstraction for the 
connection of different modules with the high-speed 
and energy efficiency associated with connections 
20 established by embedded custom code. 

To reduce the implementation cost of an SDR, 
the Diffuse ORB concept" may be extended to a 
hardware ORB, or an ORB-on-a-chip (OOC) . This chip 
is custom-designed to support hardware connectivity 
25 provided by switch matrix 360, e.g. in an SDR 

framework . 

A Diffuse ORB is used to provide the software 
architecture for the development of the waveform, 
while the underlying hardware of the system 
30 provides an efficient connectivity structure that 

is custom-tailored to an SDR application. It 
should be noted that an OOC is not a stand-alone 
solution. For this concept to work, it still 
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requires a microprocessor to provide configuration 
and management information- In this sense, an OOC 
can be considered as a communications co-processor. 
To achieve an efficient OOC solution, the 
5 Diffuse ORB concept requires development of the 

appropriate ORB and IDL code generators. Further, 
as will be evident to those skilled in the art, a 
specific solution for the switch matrix can take 
one of many forms, such as a connection fabric, 
10 bus, shared memory, or some other structure not yet 

created. 

While the invention has been described in 
terms of a single preferred embodiment, those 
skilled in the art will recognize that the 
15 invention can be practiced with modification within 

the spirit and scope of the appended claims. 



